home *** CD-ROM | disk | FTP | other *** search
/ EnigmA Amiga Run 1996 February / EnigmA AMIGA RUN 04 (1996)(G.R. Edizioni)(IT)[!][issue 1996-02][Skylink CD III].iso / earcd / util3 / idefix.lha / Docs / CacheCDFS.doc < prev    next >
Text File  |  1994-02-24  |  17KB  |  416 lines
  1.  
  2. Welcome to CacheCDFS!!!
  3.  
  4. -----------------------------------------------------------------------------
  5.  
  6. LEGAL STUFF
  7.  
  8. CacheCDFS & CDFSprefs © Elaborate Bytes, Oliver Kastl
  9.  
  10. All rights reserved.
  11.  
  12.  
  13. -----------------------------------------------------------------------------
  14.  
  15.  
  16. GENERAL
  17.  
  18. CacheCDFS is an ISO9660/RockRidge/HFS file system (DOS device driver),
  19. providing a sophisticated caching system offering a n-set associated cache.
  20.  
  21. The filesystem requires Kickstart version 2.04 or greater to work.
  22.  
  23.  
  24. INSTALLATION
  25.  
  26. Let the supplied installation program do this job!
  27. It will install the FileSystem, but you can use any editor to modify the
  28. created mountlist (see later in this document).
  29.  
  30.  
  31. THEORY OF OPERATION
  32.  
  33. Before continuing, there are a few things about cache organization that you
  34. must  know.   In  order  to  make  cache  access  as  fast and efficient as
  35. possible,  the  main cache 'buffer' must be organized in a special way.  We
  36. talk about "lines", "prefetch", "data buffer" and "minimal direct read".
  37.  
  38. These  values  all relate very closely to sector numbers.  All devices that
  39. are  used  to  store  files  on, have sectors.  One sector is a tiny bit of
  40. information  -  in case of a CDROM - 2048  bytes in size.
  41.  
  42. All  devices  have  a  controlling task (a running program) called a device
  43. driver, whos primary task it is to read and write these sectors.
  44. This might be the scsi.device for an A3000 with a SCSI-CD Rom drive, or the
  45. tandemcd.device for the wonderful TandemCD package from bsc.
  46. If a file system  (like CacheCDFS) wishes to read sectors off a drive, it
  47. must politely ask the  device  driver to  please  fetch those sectors, thank
  48. you. This device driver is sometimes called an "Exec" device driver.
  49.  
  50.  
  51. The  file system is a kind of protocol that describes how data is organized
  52. on  the  physical  device. The CacheCDFS can read ISO9660, RockRidge and
  53. MAC HFS formatted disks. (Please note: The version TandemCacheCDFS, licensed
  54. by bsc büroautomation for use with the TandemCD package can ONLY read ISO
  55. 9660 formatted CD-ROMS).
  56. As the filesystem is a kind of interface between the exec device driver
  57. controlling the hardware and AmigaDOS, it is sometimes called a "DOS" device
  58. driver.
  59.  
  60. The  term  "prefetch"  is  an indication of how many sectors the cache will
  61. read  or  write  for each physical device access.  If prefetch is set to 4,
  62. then  this  means  that  even if the DOS only asks for two sectors,
  63. four will be read.  Since each drive access is a lengthy and time consuming
  64. procedure, much time can be saved by "guessing" what sectors will be needed
  65. next.   Since  the best guess is often that "the next sector will be needed
  66. next",  prefetching  sectors  in  clusters is indeed a good thing.  Keep in
  67. mind  that  it only takes slightly longer to read four sectors than to read
  68. one.   It  would take much longer to read four sectors individually than to
  69. read them all in one go.
  70.  
  71. Furthermore, as the FileSystem really knows, how large a file actually is,
  72. and how the cd is organized, those guesses have a very good chance to be
  73. correct.
  74.  
  75. Prefetch,  or "read-ahead" if you want, can boost performance a great deal,
  76. providing you set the prefetch value not too big.
  77.  
  78. If you use too much prefetch it will not help you one bit. In fact, it will
  79. probably work against you, slowing everything down. This is because the next
  80. sector in sequence probably is NOT the next sector that  will be needed,
  81. and so the cache will be reading much more than it should, on each access.
  82.  
  83. The  morale  is  to  use  prefetch with some thought. Generally a prefetch
  84. of 2 or 4 gave very good results on ISO9660 formatted disks.
  85.  
  86. Moving  on  to  the  term  "lines".   Lines is a means of grouping together
  87. sectors  in "blocks" of a certain length.  If a cache buffer uses 32 sets of
  88. lines, this  means  that  the  cache can remember up to 32 different entries,
  89. with each entry consisting of 'prefetch' number of sectors.  To illustrate
  90. this, consider the following sketch of a 32 line cache, with a prefetch of 4:
  91.  
  92.  
  93.           Set number       Line contents
  94.  
  95.           0                [sector][sector][sector][sector] (4*2048=8k)
  96.           1                [sector][sector][sector][sector] (4*2048=8k)
  97.           2                [sector][sector][sector][sector] (4*2048=8k)
  98.           3                [sector][sector][sector][sector] (4*2048=8k)
  99.           4                [sector][sector][sector][sector] (4*2048=8k)
  100.           ....etc....
  101.           31               [sector][sector][sector][sector] (4*2048=8k)
  102.                                                             32*8k=256k
  103.  
  104.  
  105. Each  line  can  hold  any four consequtive disk sectors with this prefetch
  106. configuration.  If the file system asks for sector number 8, the cache will
  107. read  sectors 8, 9, 10 and 11 into one of the lines.  The cache will choose
  108. the  actual  line  number  to use based on the sector number, but the exact
  109. procedure is irrelevant here.
  110.  
  111. By  now  it  must be obvious that more lines also mean more space available
  112. for  sector  data,  and  therefore  a  higher  chance  that a read or write
  113. operation  will  be  able  to complete with no or only little physical disk
  114. access.  Unfortunately, it also means you have to set aside more memory for
  115. the buffers.  A compromise you often encounter with computers.
  116.  
  117.  
  118. A  typical  cache configuration is an 50-set, cache, with a prefetch (line
  119. size) of 4.  The memory required by such a cache buffer will be:
  120.  
  121.       50 sets x (4 x 2048 bytes)
  122.  
  123.     = 400k bytes
  124.  
  125.  
  126.  
  127. The CacheCDFS has also a special buffer, called "data buffer". This buffer
  128. has always the multiple size of one line.
  129.  
  130. If the line size is 4, and the data buffer has a size of 4,
  131. it is organized like this:
  132.  
  133.     Data Buffer              [line][line][line][line] (4*4*2048=32k)
  134.  
  135.  
  136. If the FileSystem does caching (it does not always, see the term "direct
  137. read" later), it checks the actual file length. In case the file is longer
  138. as the amount actually requested, the rest is read immediatly into the
  139. data buffer, and then copied to the appropriate cache line (Yes, the
  140. technical informed reader will know this method... it is called "double
  141. buffering").
  142.  
  143. The main different between the Data Buffer "read ahead" and the normal
  144. "read ahead" is as follows:
  145.  
  146. The cache lines are always filled (a "classic" read ahead cache), so
  147. even different directory sectors or sectors from different files
  148. are cached.
  149. The data buffer is a more "intelligent" special read-ahead cache line,
  150. existing only once and caching only files, if the filesystem "believes" they
  151. are worth it.
  152.  
  153. So, you can do nice caching even on machines with not much free memory.
  154.  
  155. Look at this:
  156.  
  157. 50 sets with a line size of 1 (no "directory" prefetch!), but a data buffer
  158. of 8.
  159.  
  160.     50 sets x (1 x 2048 bytes)
  161.  
  162.   = 100k bytes
  163.  
  164.   + 8 x ( 1 x 2048 bytes) (data cache)
  165.  
  166.   = 116k bytes
  167.  
  168. This gives pretty good results, even on a machine with not much memory
  169. available.
  170.  
  171. Now moving to the term "direct read". If you read large files (e.g. "off the
  172. disk animations") it is pretty useless to cache all these blocks. The file
  173. will purge all other sectors out of the cache, even such blocks like
  174. directory entries. To avoid this, you can specify a "minimum direct read"
  175. value. If DOS requests more sectors than specified here, the filesystem
  176. will bypass the cache and the device driver will copy its data directly
  177. into the callers buffer. However, if any sectors are already found in cache
  178. memory, these will be used, of course. Specifying a value of zero (0) will
  179. give you a pretty much sophisticated default. A very high value (e.g. 2000)
  180. will only do requests greater than 4MB directly, what is very unlikely
  181. to happen.
  182. Specifying a value smaller or equal to the data buffer size is not very
  183. useful, as you would in fact waste memory.
  184. For best performance, use the default (0).
  185. Before doing direct read, the Memory Type and Memory Mask of the callers
  186. buffer will be checked, if it fits to the device requirements (specified
  187. in the mountlist as BufMemType and Mask, see later).
  188. If it doesn't, tha data buffer will be used as a cache.
  189.  
  190.  
  191. It's  simply  not possible for me to present you with the recipie on how to
  192. make  a  perfect  cache.  The range of possible combinations of all the above
  193. values and the memory you which to spend for caching is simply too vast.
  194. You will have  to experiment to find the combination that best suit your
  195. needs.
  196.  
  197. The default setup installed by the installation program is a 50 set cache
  198. with 2 sectors standard "directory" prefetch and a data buffer size of 4.
  199. The memory required for this setup is shown below:
  200.  
  201.     50 sets x (2 x 2048 bytes)
  202.  
  203.   = 200k bytes
  204.  
  205.   + 4 x (2 x 2048 bytes) (data cache)
  206.  
  207.   = 216k bytes
  208.  
  209. The "minimum direct read" value defaults to zero, giving a nice default.
  210. In fact, in the above example, direct read will start with requests greater
  211. than 16k bytes.
  212.  
  213.  
  214. You can adjust these values in the filesystem's mountlist entry.
  215.  
  216.  
  217.  
  218. MODIFYING THE MOUNTLIST
  219.  
  220. The installation program has created a mountfile for you.
  221. The CDFSprefs program allows you to change some values interactively or to
  222. "try" settings without storing it in the mountfile.
  223.  
  224. The values that CDFSprefs is not able to change have been preset by the
  225. installation program and don't need to be changed.
  226.  
  227. You may of course modify values using a standard editor (like "ED" or
  228. "MicroEmacs" from your system disks), but this is strongly discouraged.
  229.  
  230.  
  231.  
  232. The created mountlist may look like this:
  233.  
  234. /***************************************************************/
  235. /*  CacheCDFS mountlist entry © 1993 Elaborate Bytes, O. Kastl */
  236. /***************************************************************/
  237.     FileSystem     = L:CacheCDFS /* The name of the game */
  238.     Device         = "scsi.device" /* Name of exec device driver */
  239.     Unit           = 0 /* exec device unit */
  240.     Flags          = 0 /* OpenDevice flags */
  241.     BlocksPerTrack = 1 /* Unused */
  242.     BlockSize      = 2048 /* True, but unused */
  243.     Mask           = 0x7ffffffe /* Memory mask for direct read */
  244.     MaxTransfer    = 0x100000 /* Maximum amount of bytes for direct read */
  245.     Reserved       = 0 /* Unused */
  246.     Interleave     = 0 /* Unused */
  247.     LowCyl         = 0 /* Unused */
  248.     HighCyl        = 5000 /* Unused */
  249.     Surfaces       = 1 /* Unused */
  250.     Buffers        = 40 /* Number of cache lines */
  251.     BufMemType     = 1 /* MEMF_PUBLIC, use whatever you require */
  252.     GlobVec        = -1 /* Do not change! */
  253.     Mount          = 1 /* Mount it immediately */
  254.     Priority       = 10 /* Priority of FileSystem task */
  255.     DosType        = 0x43443031 /* Unused, subject to change */
  256.     StackSize      = 3000 /* Minimum stack required is 3000! */
  257.     Control        = "MD=0 LC=2 DC=4 L LFC=1"
  258.    /* The Control field is for special adjustments */
  259.     /* L/S convert all file names to lowercase */
  260.     /* LV/S convert volume names to lowercase */
  261.     /* LFC/N start converting at this character */
  262.     /* LC/N/A number of blocks per cache line */
  263.     /* DC/N/A number of cache lines for the data cache */
  264.     /* MD/N/A number of blocks, when starting direct read, not using */
  265.     /* the cache. 0 will be a reasonable default (LC*DC+1) */
  266.     /* S/S Do SCSI direct commands, no Trackdisk like commands! */
  267.     /* NC/S Do NOT use TD_ADDCHANGEINT, poll for DiskChange! */
  268.     /* M/S Issue a TD_MOTOR (OFF) command after read */
  269.  
  270.  
  271. Most of the comments above are self explaining.
  272.  
  273. To modify the Mask, MaxTransfer and BufMemType consult the manual of your
  274. controller.
  275.  
  276.  
  277. The most interesting fields are:
  278.  
  279. Device: Name of the exec device driver. This can be tandemcd.device,
  280. ALF.device, oktagon.device or scsi.device, depending on the hardware you are
  281. going to use. Please note, that the TandemCacheCDFS (licensed by bsc) will
  282. ONLY work with the tandemcd stuff!
  283.  
  284. Unit: Unit number. In case of tandemcd usually 0, only if you use more than
  285. one tandem board at the same time you may need to change this.
  286. With scsi host adapters, this is usually the SCSI-ID of your cd rom drive.
  287.  
  288. Buffers: This is the default amount of sets (number of prefetch lines), that
  289. the filesystem will allocate. You can change this value during operation with
  290. the CLI command "addbuffers". Please consult your AmigaDOS manual.
  291.  
  292. Control:
  293. Here various parameters can be changed.
  294.  
  295. L: This will force the filesystem to convert all ISO file names to lowercase.
  296. Most ISO disks are mastered with all file names uppercase. If you find this
  297. annoying, you may specify L.
  298.  
  299. LV: This will force the filesystem to convert ISO volume names to lowercase.
  300. Most ISO disks are mastered with its name uppercase. If you find this
  301. annoying, you may specify LV.
  302.  
  303. LFC: lower first character. Enter the number of the character in a name, when
  304. conversion to lower case should begin. E.g. LFC=0 means, that the whole name
  305. will be converted. LFC=1 leaves the first character as it is and converts the
  306. rest of the name to lowercase.
  307. If neither "L" nor "LV" are specified, this option is ignored.
  308.  
  309. LC: LC stands for "LineCache". Here you enter the amount in sectors of the
  310. "standard" read-ahead cache (line size). The default value is 2. The minimum
  311. value is 1 (no pretetch).
  312.  
  313. DC: DC means "Data Cache". Here you enter the size of the data buffer in
  314. multiples of line caches. (e.g.: in the above example, the data cache is
  315. 16k: 4 * line size, and line size is 2 * 2k)
  316.  
  317. MD: MD is the "minimal direct read value". A read request greater or equal the
  318. amount of sectors specified here will bypass the cache and transfer data
  319. "directly" to the callers buffer, if the buffer fulfills the requirements
  320. specified in BufMemType and Mask and the length of the request is not greater
  321. as the value specified in MaxTransfer. 0 will give you a nice automatic
  322. calculated default, based on the algorithm MD = LC x DC + 1.
  323.  
  324.  
  325. The following control entries are only for some special configurations:
  326.  
  327. S: This will cause CacheCDFS to use SCSI-direct commands instead of the
  328. standard "trackdisk-like" commands. This will only work with a SCSI host
  329. adapter and a SCSI cdrom drive, of course. This option is useful for older
  330. SCSI host adapters (e.g. very early ALF scsi controllers) having problems
  331. with CDROM drives. You should only specify this option, if you encounter
  332. problems.
  333.  
  334. M: This will cause a TD_MOTOR off command to be issued after CMD_READ.
  335. It is ignored, if "S" is set.
  336. This option is neccessary for some scsi adapters, that issue a "prevent
  337. medium removal" command (e.g. GVP-Series II). If you can't remove an inserted
  338. CD, try this option.
  339.  
  340. NC: This is the "NoChangeInt" option. It will tell the filesystem, NOT to
  341. install a diskchange interrupt server. Instead it will "poll" every three
  342. seconds, if the medium has been changed. It is useful for host adapters
  343. having trouble to recognize a disk change with certain cd rom brands (e.g.
  344. Commodores A2091 and Apple CD Rom. Specify "S" and "NC", and it will work).
  345. You must use this option, too, if your controller rejects working without the
  346. S option described above. Only specify NC if you REALLY encounter any problems
  347. with medium change recognition!
  348.  
  349.  
  350.  
  351. ERRORS WHILE MOUNTING
  352.  
  353. Mounting may indeed fail, if a severe error condition occures.
  354.  
  355. The filesystem gives you lots of nice error messages, described below.
  356.  
  357. "Filesystem startup invalid!"
  358. Come on... you tried to mount the filesystem as a handler.
  359.  
  360. "Environment vector invalid!"
  361. Same as above.
  362.  
  363. "Control entry in mountlist missing!"
  364. You must specify a "Control" field in your mountlist for the filesystem to
  365. work!
  366.  
  367. "Error while parsing Control field in Mountlist: ..."
  368. You specified something weird in the control field. Check your mountlist!
  369.  
  370. "Illegal number of cache lines (Buffers)"
  371. "Buffers" must be greater than zero.
  372.  
  373. "Illegal value for data cache"
  374. DC in control field must be greater than zero.
  375.  
  376. "Illegal number of sectors for cache line size"
  377. LC in control field must be greater than zero.
  378.  
  379. "Illegal number of sectors for minimal direct read"
  380. MD in control field must be greater or equal than zero.
  381.  
  382. "Out of memory! Cannot allocate buffers!"
  383. Should be obvious. Reduce "Buffers", or DC and LC in control field.
  384.  
  385. "Cannot open ...device unit ..."
  386. The hardware driver for your cdrom can't be opened for some reason.
  387. This can have various reasons. Check the following:
  388. Is the driver present?
  389. Is the device name corecctly spelled? Note that the device name is case
  390. sensitive!
  391. Is the correct unit number specified?
  392. Is the hardware (e.g. the cdrom controller or scsi-host adapter) present?
  393. Is the cdrom correctly connected?
  394. Is it switched on?
  395.  
  396. "You really shouldn't start this program directly!"
  397. You loaded the filesystem as a CLI command by typing its name. Very funny.
  398.  
  399.  
  400. ERRORS DURING OPERATION
  401.  
  402. The cdrom does not respond at all:
  403. If you are using a scsi host adapter, try specifying the "S" flag in the
  404. control field in the mountlist.
  405.  
  406. The filesystem does not detect medium changes:
  407. Probably the hardware driver has problems with your cdrom drive. Try
  408. specifying the "NC" option in the control field in the mountlist.
  409. You can also manually cause a diskchange by using the "DiskChange" command
  410. from the CLI.
  411.  
  412.  
  413.  
  414. END OF DOCUMENT
  415.  
  416.